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ABSTRACT 


Regulatory Technology (RegTech) is the use of technology to ensure regulatory compliance. RegTech has 
been used not only by financial industries but also by non-financial industries. On the other hand, Supervisory 
Technology (SupTech) is the use of technology to facilitate and enhance supervision activities and processes. 
RegTech and SupTech are underpinned by popular technologies, such as Big Data Analytics, Artificial 
Intelligence, Machine Learning, etc. However, it is hard to find RegTech / SupTech discussions in computer 
science or system information disciplines. Hence, no reference can guide an organization to develop 
RegTech/SupTech. Therefore, it is necessary to design a framework for developing RegTech/SupTech. The 
framework is developed using Design Science Research Methodology (DSRM). The proposed framework 
consists of nine components, i.e., regulation, risk management, environment constraint, functionality, 
technology, data, people, project strategy & management, and repository. Each of the components suggests 
recommended output(s) in order to develop a RegTech/SupTech. The proposed framework covers the 
components of existing frameworks and gives two additional components. Hence, this research contributes 
to provide an alternative framework for developing RegTech/SupTech. 
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1. INTRODUCTION 


Regulatory Technology (RegTech) is the 
use of information technology (IT) in regulatory 
monitoring, reporting, and compliance context [1]. 
Initially, RegTech was a subset of Financial 
Technology (fintech) [2]. RegTech was used by 
fintech companies to help them effectively and 
efficiently fulfilling regulatory requirements [2]. 
Some RegTech utilizations are money laundering 
prevention [3], capital market transaction 
monitoring, and minimizing compliance violation 
risk [4]. In its journey, RegTech then became 
independent and separated from fintech [1], [3], [5]. 
Furthermore, RegTech can be adopted outside the 
financial industry, e.g., a tool that helps front-liner 
social workers decide righteous social programme 
recipients [6], real estate [7], and ensures compliance 
in the health industry [8]. 

Another IT utilization close to RegTech has 
been adopted by the supervisor authorities. Its name 
is Supervisory Technology (SupTech). SupTech has 
been adopted by financial authorities to supervise 
massive amounts of financial service providers [9]. 


SupTech was defined as the use of IT to perform 
supervisory responsibilities [10]. SupTech was also 
described as the use of technologies to facilitate and 
enhance supervisory activities and processes [11]. 
Some others described SupTech as a RegTech in the 
supervisory context [12], a RegTech that is used in 
supervision [13], [14], [15], and technology 
innovation that is similar to RegTech [16], [17]. It 
can be concluded that SupTech is similar to RegTech 
as a concept but has different functionality or 
purpose. 

Regulatory compliance is also an important 
matter in non-financial industry. However, RegTech 
and SupTech discussions are easier to be found in 
banking, finance, or law publications. RegTech and 
SupTech discussion are scarce in computer science 
or system information research even though they 
have utilized new emerging technologies (Big Data 
Analytics, AI, Distributed Ledger Technology, etc.) 
[18]. Furthermore, based on [19] and other recent 
times searches, there is no a single reference that can 
be referred to guide an organization (as general, not 
limited to a financial organization) in developing a 
RegTech or SupTech. 
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Three closest publications was found, 1.e., 
[20], [21], [22]. First, the publication was about a 
framework for integrating a RegTech with a digital 
transformation model of bank treasury [21]. Instead 
of disturbing the applied transformation model, a 
RegTech should be integrated into the current 
transformation model [21]. This framework 
explained the importance of integrating RegTech’s 
functionalities and technologies. This framework 
was specified for bank treasury and did not explain 
how to develop a RegTech. Second, the publication 
was about seeing RegTech from multidimensional 
perspective [20]. It did not explain about how to 
develop a RegTech. It explained more about what 
RegTech is. It gives the reader a complete RegTech 
concept. However, it still discussed RegTech from a 
financial point of view. Third, this limited-published 
publication contained detailed step-by-step RegTech 
adoption [22]. However, this publication did not 
show a full explanation and specified only for its 
members (banks in Hong Kong). 

Based on the explanation above, there is 
still a need for a framework that can be used to help 
an organization develop a RegTech or SupTech. The 
research question is “how to design the generic 
framework for developing RegTech/SupTech?”. 
Hence, this paper’s research objective was 
“designing the generic framework for developing 
RegTech/SupTech”. 


2. RESEARCH METHOD 
2.1. Research Methodology 


Design Science Research Methodology 
(DSRM) [23] is adopted as the _ research 
methodology. DSRM is suitable for information 
system research with artificial artefacts. DSRM 
contains six phases, 1.e., (1) identify & motivation, 
(2) define objectives of the solution, (3) design & 
development, (4) demonstration, (5) evaluation, and 
(6) communication. The phases’ flow is presented in 
Figure 1. The first phase of the DSRM produces 
problem identification. According to the identified 
problems, motivation for research will be 
formulated. In the second phase, the identified 
problems and motivation determine a solution. A 
research objective will then be defined firmly. These 
first two phases are usually described in the 
introduction part of a research paper. This paper 
states the research problem and objective in the 
introduction section. Thus, the following subsection 
explains the third phase. The demonstration and 
evaluation are presented at the Discussion 
subsection. The communication phase 
implementation is this paper itself. 
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Figure 1: DSRM Phases [23] 
2.2. Design & Development 


RegTech and SupTech are close concepts. 
Some researchers said about it, e.g., SupTech 1s 
RegTech in the supervision context [12], RegTech 
that is used in supervision [13], [14], [15], and 
technological innovation that similar to RegTech 
[16], [17]. The difference between RegTech and 
SupTech is in functionality level. Hence, in this 
paper, a single framework is designed. The 
framework will be able to be used to develop both 
RegTech and SupTech. In order to cover all the 
important component of RegTech and Suptech, the 
research design follows these four steps: (1) stating 
the design requirement, (2) comparing closest- 
related frameworks, (3) combining the components 
and proposing new components, and (4) 
adding relation between the combined components. 
Those steps are presented in these following 
subsections. 


2.2.1. Stating the design requirement 


The design requirements will define the 
quality of the artefact. They must reflect the 
characteristics that are mentioned as the research 
objective, i.e., (1) RegTech/SupTech, (2) generic, 
and (3) framework. Besides that, the design 
requirements must be mapped into suitable 
evaluation criteria for information-system artificial 
artefacts. The first characteristic to be considered is 
RegTech/SupTech. In order to gain the most 
essential points from RegTech/SupTech, the most 
mentioned key words of RegTech and SupTech 
definitions are extracted. The collection of 
definitions by [19] are used. From that collection, the 
words mentioned more than ten times from 35 
definitions are picked as key words: (1) technology, 
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(2) regulatory, (3) compliance, (4) requirements, (5) 
use, and (6) reporting. The key word number 4 
(requirement) always showed side by side with the 
key word number 2 (regulatory). Hence, requirement 
is removed as a key word because it refers to the 
same point: the regulatory. The key word number 3, 
number 5, and number 6 describe about 
RegTech/SupTech as a function. Hence, those three 
key words fall into one general term, functionality. 
From the previous analysis, it is concluded that three 
main points of RegTech/SupTech are (1) 
technology, (2) regulatory/regulation, and (3) 
functionality. 

The second characteristic to be considered 
is generic. In this paper, generic (characteristic) 
refers to the use of a component or a terminology that 
is not industry specific and/or organization specific. 
The last characteristic to be considered is the 
framework. The final framework form is_ the 
collection of components, their relations, and their 
descriptions. It is intended to give a conceptual view 
of developing a RegTech/SupTech and how to 
develop a RegTech/SupTech solution. From the 
framework characteristic, there are two main points, 
1e., (1) conceptual view and (2) development 
processes. The design requirements of this research 
are detailed in Table 1. 


Table 1: The Design Requirements 

Characteris Design 
tics Requirements 

RegTech/S_ | The main points 
upTech of 
RegTech/SupTech 
concept must be 
included as 
components. 
The framework 
must use a generic 
component and/or 
term. 


Explanation 


The main points of 
RegTech/SupTech: (1) 
technology, (2) 
regulatory/regulation, 
and (3) functionality 


Generic refers to the use 
of component or term 
that is not industrial 
specific and/or 
organizational specific. 
The explanation about 
conceptual view and 
RegTech/SupTech 
solution development is 
the main points of 
framework 
characteristic. 


Generic 


The framework 
must explain the 
conceptual view 
and explain how 
to develop a 
RegTech/SupTech 
solution. 


Framework 


After stating the design requirements, the 
quality measurements for the evaluation phase are 
formulated. Considering the limited resources, an 
evaluation criterion is selected, i.e., completeness. 
Completeness is one of the recommended criteria for 
evaluating a model-type artefact. As explained in 
section 3 two aspects are used to evaluate. Because 
there is only a single evaluation criterion, all the 
design requirements are fallen into completeness. 
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The evaluation points are shown in Table 2. The 
maximum possible evaluation point is 4. If this 
framework gains 4 points, it means that the 
framework fulfils all the design requirements and 
simultaneously fulfils the completeness criterion. 


Table 2: Quality Measurement of Proposed Artefact 


R penen Evaluation Points 
equirements 

The main points | e The Framework contains a component 
of RegTech/ called ‘technology’. (1 point) 
SupTech e The Framework contains a component 


concept must be 
included as 
components. 


called ‘regulatory’/ ‘regulation’. (1 
point) 

e The Framework contains a component 
called ‘functionality’. (1 poi 


The framework | There is not any industrial specific and/or 


must use a organizational specific component / term 
generic that is included in the framework. (1 point) 
component 

and/or term. 


The framework 
must explain the 
conceptual view 
and explain how 
to develop a 
RegTech/SupTe 
ch solution. 


e The Framework contains explanation 
about conceptual view. (1 point) 

e The Framework contains explanation 
about RegTech/SupTech development 
processes. (1 point) 


2.2.2. Comparing closest-related frameworks 


(a) Closest-related frameworks 

In order to gain comprehensive framework 
components, the components from closest-related 
frameworks ({20], [21], [22]) are compared. 
Comparision makes it possible to identify 
components that have the same context even though 
they have different names. Besides that, comparison 
provides an understanding of the weakness of each 
framework. The first framework is about RegTech 
development in bank treasury [21]. The research 
explored the development of RegTech that needed to 
be implemented inside a bank treasury. However, the 
bank treasury environment was bounded by its 
current digital transformation model. This research 
proposed an integration of RegTech and bank 
treasury digital transformation model, the Smart 
Digital Transformation Model (SDTM). This 
approach can lead to better alignment of strategic 
decision-making and _ regulatory management 
practices. The proposed way to develop RegTech is 
as follows. First, all regulatory activities are listed 
and then integrated with other activities inside 
SDTM. Second, those activities are formed into 
digital use cases and mapped with suitable 
technologies. All those steps do not give any 
practical way to develop a RegTech. Any practical 
development process is in SDTM. It is not published 
through this publication. Furthermore, SDTM is not 
a generic-type framework. Another highlight of this 
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research is about five RegTech service areas: (1) 
regulatory reporting, (2) compliance, (3) transaction 
monitoring, (4) identity management and control, 
and (5) risk management. 

The second framework is  Miulti- 
dimensional RegTech Framework [20]. This 
research provided a comprehensive and multi- 
dimensional framework of RegTech (Figure 2). 
Through it, the authors wanted to provide RegTech’s 
main body of knowledge. This research used 
bibliometric analysis and systematic review to 
gather the information. The multi-dimensional 
framework consists of four main dimensions: (1) 
aspects defining regulation and technology, (2) the 
role of data, (3) stakeholders and applications, and 
(4) benefits and risks. In the first dimension, the 
basic form of RegTech is illustrated. RegTech is 
formed by regulation and technology. In the second 
dimension, the framework explains the imperative 
roles of the data through some examples. In the third 
dimension, the framework explains various types of 
stakeholders and the five functions of RegTech. 
Those five functions are compliance, monitoring, 
risk management, reporting, and operation. In the 
last dimension, the framework warns the readers that 
every RegTech benefit always comes with risk. All 
the dimensions give the readers a_ clear 
understanding of what RegTech is but do not give 
any detail of how to develop one. 


Dimension #2 


Data 


Regulation Regulated 


Entities | | Applications 


Regulators; 


RegTech 
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» Applications 
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Figure 2: Multi-dimensional RegTech Framework [20] 


The last framework is RegTech Adoption 
Framework [22]. This publication is a practice 
guidance document. It was designed to provide 
banks with an overview of RegTech. In this 
document, a framework for  RegTech 
implementation was introduced. The framework is 
intended to replace a use case-led approach in 
developing RegTech. The framework is presented in 
Figure 3. This framework provides more complete 
guidance on developing a RegTech than others. 
However, the details of the framework’s components 
are not available in this document. 

(b) Result of the comparison 


Some components describe the same things 
but use different terminologies. Hence, before 
comparing, the same-meaning-but-different- 
terminology components are identified and put into 
the same group. The comparison result is shown in 
Table 3. From that table, it can be seen that each 
framework has its weakness. By combining all 
components of all those frameworks, a set of 
comprehensive RegTech/ SupTech components is 
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Figure 3: RegTech Adoption Framework [22] 
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2.2.3. Combining the components and 
proposing new components 


After comparing the frameworks, a 
comprehensive set of framework components are 
collected. If there are other important aspects to be 
considered, new components can be added. From 
Table 3, it is found that there are seven groups of 
components. Some groups that have various 
terminologies are renamed. The seven final 
components are (1) Regulation, (2) Technology, (3) 
Data, (4) People, (5) Risk Management, (6) Project 
Strategy & Management, and (7) Functionality. 

Two aspects should be added. First, 
Developing a RegTech has to consider the currently 
implemented digital transformation model [21]. In 
general, a particular constraint needs to be 
considered in designing or implementing a solution. 
This constraint can be an enterprise architecture or 
any IT-related governance. Hence, a new component 
is proposed. It is called (8) Environment Constraint. 
Second, because there are approaches of project 
management concepts and some __ enterprise 
architecture concepts in the combined components, 
it is decided to propose one more component, 1.e., (9) 
Repository. 


2.2.4. Adding relation between the combined 
components 


In this last step, the combined components 
are equipped with relations. These relations give a 
more understanding of the RegTech/SupTech 
development. Now, each component has its position 
relative to the other components. Some of the 
combined components can be sequenced. Regulation 
is the core of RegTech/SupTech hence it has to be 
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the driver of RegTech’s / SupTech’s Functionality 
requirement. Regulation could also drive risk 
mitigation. Hence, it is also the driver of Risk 
Management. On the other hand, risk mitigation 
could also be a driver for Functionality 
requirements. Data, Technology, and People need to 
support the Functionality requirements. The delivery 
of those mentioned components is done by Project 
Strategy & Management. All the design artefacts or 
deliverables are stored in Repository. For simplicity, 
this relationship is illustrated in Figure 4. 


3. RESULT & DISCUSSION 


3.1. The Proposed RegTech and SupTech 
Development Framework 


The proposed generic components are 
shown in Figure 4. There are nine components in it. 
For simplicity, from here and on, those nine 
components are called with the name “FW” + each 
of their number. For example, Regulation will be 
called FW1, Risk Management will be called FW2, 
and so on. 


(a) FWI1 (Regulation) 

Regulations drive the requirement of 
RegTech/SupTech functionality. RegTech/SupTech 
can be based on a regulation, multiple regulations 
simultaneously, or even only generic functionality 
required by all organizations, such as reporting 
activities [19]. In this paper, the regulation refers not 
only to a formal one but also to an organization-level 
internal policy. Some recommended things to be 
done here are understanding the regulatory 
structures, the regulation governance and 
management, and regulation interpretation. The 
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Figure 4: The Proposed Framework for Developing RegTech/SupTech 
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purpose of this component is to formulate 


functionality requirements, not complex 
requirements but somewhat tacit ones. 
(b) FW2 (Risk Management) 

Newly released regulations drive the 


organization to re-evaluate its risk register. Every 
single possible incident due to regulation factors 
needs to be considered. If the possible incident is 
terrible for the organization, it becomes a risk. 
Through risk management processes, every risk has 
its response. Some of the risk responses can drive a 
RegTech/SupTech functionality requirement. The 
recommended things to be done here are 
understanding the risk register and responses. The 
purpose of this component is the same as FW1. 


(c) FW3 (Environment Constraint) 

Nowadays, it is common for an 
organization to have enterprise architecture. It will 
provide an _ organization with a controlled 
development policy. Implementing 
RegTech/SupTech in an organization must consider 
this limitation. RegTech/SupTech development 
must not disturb the existing implemented strategy. 
This component's purpose is to give an early warning 
for RegTech/SupTech developers so they will only 
design something feasible to implement. 


(d) FW4 (Functionality) 

This component is intended to bring the 
tacit idea (requirement) into more detailed 
requirements. For that purpose, FW3_ contains 
solution defining and business architecture. In FW3, 
a solution is formulated. A solution architecture 
concept can be approached with an Enterprise 
Architecture concept [24]. Hence, solution 
architecture is elaborated in business, data, 
application, and technology architecture. The scope 
of FW3 is only within solution defining and business 
architecture designing. The recommended things to 
be produced here are (1) solution design, (2) 
business architecture requirements, and (3) business 
architecture. 


(ce) FW5 (Technology) 

Technology requirements are formulated 
Based on _ business, data, and application 
architecture. Technology architecture must be able 
to serve all three other architectures. In this paper, 
the technology architecture refers to the same 


concept with infrastructure architecture. The 
recommended things to be produced here are (1) 
technology architecture requirements and (2) 


technology architecture. 
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(f) FW6 (Data) 

Business architecture (in FW3) drives data 
architecture and application architecture 
requirements. In this component, those requirements 
need to be answered in the form of data architecture 
and application architecture. The recommended 
things to be produced here are (1) data architecture 
requirements, (2) data architecture, (3) application 
architecture requirements, and (4) application 
architecture requirements. 


(g) FW7 (People) 

In the enterprise architecture concept, 
people is included in business architecture. Some 
business architecture artefacts must be detailed into 
actors, roles, or people. Hence, in FW6, it is decided 
to cover other topics. FW6 has a purpose to design 
talent needs, communication strategy, and 
knowledge management. 


(h) FW8 (Project Strategy & Management) 

This component is an original component 
from RegTech Adoption Framework [22]. In that 
publication, this component is used to deliver 
RegTech into a live system and monitor it. RegTech 
is delivered through a project. This component has a 
role as an implementation step. The solution 
architecture is brought to the implementation by 
FW8. 


(i) FW9 (Repository) 
This component is designed to be a storage 
of the documentations. 


3.2. Discussion 


This subsection is intended to discuss the 
usability of the proposed framework and its quality. 
In order to provide proof of usability, a 
demonstration is required. After that, an evaluation 
is necessary to be done to measure the quality of the 
proposed framework. These two activities are the 
fourth and fifth phase of DSRM. 

First, the demonstration is done through a 
simulation case. This simulation is based on a real- 
world case but without a real-world respondent. A 
case about fraud detection of a financial service 
provider’s (FSP) financial report is chosen. This 
detection is necessary for preventing further 
national-level economic instability. This fraud 
detection will be a massive help for a country's 
financial service authority (FSA). Before this case is 
explained into each component, Figure 5 can give a 
conceptual view of this SupTech development. In 
this paper, the demonstration does not include the 


aaa a a 
2636 


Journal of Theoretical and Applied Information Technology 
31% March 2024. Vol.102. No 6 


ISSN: 1992-8645 


FW8 and FW%9. It is because the delivery (FW8) of 
the design aspect (FW1-FW7) into a live system 
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innovation. These documents are needed to 
formulate design solutions in the following 
components. 


requires a considerable number of resources. Thus, 
the FW9 is also skipped. 


(a) FWI1 (Regulation) 

The National Law appointed an institution 
named Financial Service Authority (FSA) to govern 
and manage all financial service providers (FSP). 
The chief of the FSA is allowed to publish any 
necessary policy to manage FSP. The National Law 
demands that the FSA protect national economic 
stability in any necessary way. In order to fulfil this 
responsibility, the FSA published a regulation that 
obligates every FSP to send an annual report about 
its business. 


(b) FW2 (Risk Management) 

Based on the responsibility mentioned 
above in FW1, the FSP has been manually analysing 
the FSP’s annual report. This manual analysis brings 
considerable risk. The manual analysis takes much 
time and hence endangers national economic 
stability. It is necessary to change the manual 
analysis into machine automation. Besides that, the 
periodic annual reporting is required to change into 
pull-access reporting so the FSA can supervise the 
FSP’s internal report when needed. 


(c) FW3 (Environment Constraint) 
The FSA needs to prepare its enterprise 
architecture or any other policy related to IT 


Based on risks that related 
to reporting requirement, 
itis needed to have a 
quicker tool to detect 
reporting frauds 


_y _ Risk 
/ Management 


The quicker tool to detect reporting frauds has 
the ability to: 
(1) read the report, (2) understand the report, 
(3) detect the fraud, and (4) notify the fraud 


Regulations about annual 
reporting requirement for 
all FSP 


Technology 


The Data Architecture: 
(1) data flow pyramid, (2) ERD, 
(3) Matrix of Data vs Owners 


The Technology Architecture: 
Matrix of applications vs data vs 
technology 


The Application Architecture: 
(1) Matrix of business architecture vs 
applications vs data 
(2) Application Design in UML 


Those abilities become a requirement for 
business architecture. The business 
architecture is explained in form of BPMN 


7. People 


(d) FW4 (Functionality) 

In the FW2, the simple solution was 
mentioned. From that tacit solution idea, then, it is 
deepened into more detailed design requirements. 
The design requirements of the fraud detection 
solution are (1) the solution must be able to read the 
report, (2) the solution must be able to understand 
the report, (3) the solution must be able to detect 
fraud, and (4) the solution must be able to notify 
whenever frauds are detected. These requirements 
determine the business architecture of the solution. 
All business architecture artefacts can be employed 
here. For example, the business architecture can be 
presented using BPMN, as shown in Figure 6. 


(ec) FW6 (Data) 

The data component is designed prior to 
technology. Based on the BPMN, the design 
requirement of data architecture can be determined. 
The data architecture must be able to (1) manage 
structural and semi-structural data and (2) manage 
catalogue and metadata. The data architecture is 
explained using ERD, as shown in Figure 7. After 
designing data architecture, the design requirements 
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Figure 5: The Overview of the Demonstration 
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Figure 6: The BPMN of Fraud Detection 


of application architecture are determined. The 
application architecture must be able to (1) handle 
Create-Read-Update-Delete (CRUD) activities, (2) 
transfer data from machine to machine, (3) read and 
understand the report, (4) detect fraud, and (5) 
handle visualization for human counterparts. The 
application architecture is explained in Table 4 and 
Table 5. 


(f) FWS5 (Technology) 

FW5 is designed after business 
architecture, data architecture, and application 
architecture are done. Based on other architectures, 
the requirements of technology architecture are (1) 
technology that can handle data transfer through API 
tool, (2) technology that can handle CRUD 
activities, (3) technology that can handle NLP tools, 
(4) technology that can handle ML tools, and (5) 
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technology that can handle notifications. Hence, the 
technology architecture is shown in Table 6. 


Table 4: Application Requirements vs Application 
Selection Matrix 


Application Architecture 
Requirements 
CRUD activities 


Read & understand the report 


Visualization 


API tool, web portal 


DBMS, NLP tool 


NLP tool, ML tool 
Web Portal 


Annual Report 


Pulled-Data Based 
Report 


Figure 7: The ERD of Fraud Detection 


Table 6: Technology Requirements vs Technology 
Selection Matrix 
Technology 
Architecture 


Technology 


Handle API tools 
Handle CRUD activities 


Web 
Cloud, Data Lake 
Cloud, NLP 
Cloud, ML 


Handle NLP tools 
Handle ML tools 


Handle Notification Web, Email, Mobile 


(g) FW7 (People) 

Some talents needed 
SupTech are solution architect, data engineer, 
database administrator, software engineer, data 
scientist, and fraud analyst. The communication 
strategy includes board of director meetings, 
internalization, SupTech course, engineering team 
meetings, etc. The talent needs and communication 
strategy should be detailed in comprehensive 
documents. 


in developing 
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(h) FW8 (Project Strategy & Management) & FW9 
(Repository) 
In this paper, these components are not 
demonstrated. 


After demonstrating the usability of the 
proposed framework, the evaluation of its quality is 
conducted. The proposed framework is evaluated by 
checking the fulfilment of design requirements. 
Besides that, the evaluation criterion is also checked. 
Those evaluations are shown in Table 7. 

Based on the demonstration and evaluation, 
it is showed that the proposed framework fulfills the 
usability and the quality. The proposed framework 
can be guidance in designing a SupTech. The 
demonstration showed the outputs of the most part 
of the framework. The evaluation shows that the 
proposed framework gains the maximum point, 6 
points. Hence, it can be concluded that the proposed 
framework fulfills the quality, based on the design 
requirements, and the completeness criterion. 

The proposed framework covers all 
components from previous existing framework and 
adds two new components. It is mean that, at least, 
the proposed framework can play as an alternative 
framework in developing RegTech/SupTech. 
However, as mention above, the demonstration of 
this research is done by using a simulation case. This 
way of demonstration is not sufficient yet to prove 
the easiness implementation in real case, especially 
in complex case of RegTech or SupTech. Future 
research is still needed to perfect the proposed 
framework. 


4. CONCLUSION 


RegTech and SupTech was proven in 
enabling regulatory compliance processes to be 
more effective and efficient. Because of that, 
RegTech and SupTech are needed by broader 
industry, not only financial industry. There is no 
guidance on how to develop a Regtech/SupTech. A 
reference is needed to guide in developing 
RegTech/SupTech. Through DSRM, a framework 
for developing RegTech/SupTech is produced. 

The proposed framework consists of nine 
components. They are (1) regulation, (2) risk 
management, (3) environment constraint, (4) 
functionality, (5) technology, (6) data, (7) people, (8) 
project strategy & management, and (9) repository. 
The regulation and risk management component 
drive RegTech/SupTech development. Those two, 
with consideration of environment constraint, 
determine a solution idea, so then the functionality 
component elaborates it. The functionality requires 
support from technology, data, and _ people 
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component to make a comprehensive solution 
design. Through project strategy & management, the 
design will then be brought into implementation. All 
the activities in the development process are 
documented inside a repository. A demonstration 
was conducted to see the usability of the proposed 
framework. The proposed framework was used to 
help designing a SupTech. The evaluation of the 
proposed framework shows that the proposed 
framework fulfils all the design requirements and 
completeness criterion. 

This research contributes an alternative 
framework for developing RegTech/SupTech. The 


Table 7: Quali 
Design Requirements 


The main points of 
RegTech/ SupTech concept 
must be included as 
components. 


Evaluation Points 


e The Framework contains a 
component called ‘technology’. 
(1 point) 


The Framework contains a 
component called ‘regulatory’/ 
‘regulation’. 

(1 point) 

The Framework contains a 


component called ‘functionality’. 


(1 point) 


The framework must use a 
generic component and/or 
term. 


There is not any industrial specific 
and/or organizational specific 


framework. 

(1 point) 
The framework must 
explain the conceptual 
view and explain how to 


component / term that is included in the 


e The Framework contains explanation 
about conceptual view. (1 point) 
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proposed framework gives two _ additional 
components to perfect existing components from 
previous framework. Besides that, its generic 
characteristic allows this framework to be used in 
various industries. However, the proposed 
framework still has room for improvement. Some 
future works of applied research with various fields 
will be excellent input for improving the framework. 


Measurement of Proposed Artefact 


Evaluation 
Criterion _Inplenenaton 


The proposed 
framework is free 
from industrial 
terminology and 
industrial artefact 


Completeness 


develop a 
Peele e The Framework contains explanation Figure 5 
solution. about RegTech/SupTech 

development processes. 

(1 point) 

TOTAL POINT 6 
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